Scrum hielt als Vorgehensmodell für das Projektmanagement in den letzten Jahren in vielen Unternehmen Einzug. Ganz so toll, wie von vielen propagiert, läuft es aber nicht immer damit. Das motivierte Bernhard Löwenstein dazu, fünf Thesen zu formulieren, die in Folge von fünf Scrum-Experten auf Herz und Nieren geprüft werden.

THESE 1

Bernhard Löwenstein: Die meisten Unternehmen machen nicht Scrum, sondern verwenden lediglich einen Scrum-ähnlichen Prozess. So werden beispielsweise immer wieder die Daily Stand-ups oder die Retrospektiven nicht gemacht. Dadurch geht aber manch großer Vorteil verloren, dessen sich die Unternehmen aber gar nicht bewusst sind.

Frank Düsterbeck: Diese These unterstütze ich. Die Sätze „Das Beste aus beiden Welten“ oder „Wir haben Scrum auf unsere Belange zugeschnitten“ höre ich relativ häufig. Ursache hierfür ist nicht selten die Angst, mit allen Konsequenzen von Scrum umgehen zu müssen – angefangen bei den Rollen bis zum potenziell auslieferbaren Produkt. Scrum ist ein Problemsensor, und als solcher zeigt es alle Hindernisse sehr schnell auf: in der Organisation, bei den Menschen und deren Interaktionen, bei den Prozessen und Praktiken und in den Technologien. Das muss man aushalten können und an die Ursachen ran. Die konsequente Abarbeitung der Hindernisse zur Optimierung des Wertstroms schaffen aber nur die wenigsten. Den Sensor beispielsweise durch das Weglassen der Retros zu verlieren, ist manchmal viel einfacher, bedeutet aber nichts anderes als die Ursachen zu ignorieren und das wirkliche Potenzial von Scrum nicht zu nutzen.

THESE 2

Bernhard Löwenstein: Bei den früher klassischen Vorgehensmodellen gab es immer einen großen Aufschrei der Entwickler, wenn Codeteile im Nachhinein geändert werden mussten. Bei Scrum sind in den meisten Projekten die zwischendurch durchgeführten Codeadaptierungen noch wesentlich umfangreicher, allerdings wird dies nicht bewusst wahrgenommen. Um es mit einer Metapher auszudrücken: Am Ende steht zwar ein fertiges Haus, aber auf dem Weg dahin hat man oft in Summe auch ein ganzes Haus wieder eingerissen.

Frank Düsterbeck: Das sehe ich anders. Scrum – wenn ernst genommen – führt die Entwickler dahin, von vornherein Wert zu schöpfen. Projekte, in denen erst das gesamte Datenmodell und dann die Stammdaten ausprogrammiert werden, sollten demnach der Vergangenheit angehören. Gerade in letzteren Projekten war es eher notwendig, größere Teile oder sogar alles noch mal über den Haufen zu werfen. Insbesondere, weil man im Vornherein eben nicht alles weiß. Eine iterative, evolutionäre Entwicklung wie mit Scrum schützt vor Fehlentwicklungen und führt daher nicht zwangsweise zu mehr Codeadaptierung.

Scrum – wenn ernst genommen – führt die Entwickler dahin, von vornherein Wert zu schöpfen.

Der Agile & Culture Track auf der JAX 2018

THESE 3

Bernhard Löwenstein: Es wird bei Scrum vorab kaum mehr etwas spezifiziert, sondern die Produktivität wird vorrangig daran gemessen, wie schnell die Entwickler loslegen und etwas Herzeigbares liefern. Das endet oftmals in Code, der deutlich eleganter geschrieben hätte werden können, oder in Architekturen, die sich später als suboptimal herausstellen.

Frank Düsterbeck: Das sehe ich anders. In Scrum ist es durchaus sinnvoll und notwendig, mit geeigneten Praktiken (z. B. Personas, Story Mapping) vorab Erkenntnisse zu gewinnen und das Product Backlog für die ersten Sprints vorzubereiten, um nicht ins Blaue loszucoden. Natürlich ist es wichtig, schnell Wert zu schöpfen. Dies sollte immer das Ziel sein. Denn nur dann werden wir die Hindernisse, die der Wertschöpfung entgegenstehen, konsequent eliminieren. Das hat aber meiner Meinung nach keinen negativen Einfluss auf die Codequalität. Diese hängt eher vom Selbstverständnis der Entwickler, dessen Manifestation in der Definition of Done und der konsequenten Einhaltung dieser ab. Gerade in rein sequenziellen Projektumfeldern, in denen Refactoring kein kontinuierlicher Prozess ist, leidet die innere Qualität stärker als in agilen Umfeldern, in denen Refactoring kontinuierlich stattfindet.

THESE 4

Bernhard Löwenstein: Entwickler lieben Scrum vor allem deshalb, da die lästige Arbeit des Dokumentierens auf ein Minimum reduziert wird und das Programmieren im Vordergrund steht. Das erzeugt den Eindruck, dass man stets produktiv ist, auch wenn dies gesamtheitlich betrachtet nicht so der Fall ist.

Frank Düsterbeck: Längst nicht alle Entwickler lieben Scrum – ganz im Gegenteil! Durch die hohe Transparenz können sich Menschen, die beispielsweise in einer Misstrauenskultur gearbeitet haben, stark unter Druck gesetzt fühlen und Scrum negativ empfinden. Es gibt eben keine Möglichkeit, sich zu verstecken, sondern Vertrauen und Offenheit sind die Basis des guten Miteinanders. Was die Dokumentation angeht, so macht Scrum dort keine Vorgaben. Das bedeutet: Auch in Scrum-Umfeldern kann viel Dokumentation anfallen (z. B. in der Medizintechnik). Die These ist eher eine beliebte Fehlinterpretation der agilen Werte und hat mit Scrum eigentlich gar nichts zu tun.

In Scrum ist es durchaus sinnvoll und notwendig, mit geeigneten Praktiken (z. B. Personas, Story Mapping) vorab Erkenntnisse zu gewinnen und das Product Backlog für die ersten Sprints vorzubereiten, um nicht ins Blaue loszucoden.

THESE 5

Bernhard Löwenstein: Wer Scrum mit den früher klassischen Vorgehensmodellen vergleicht, macht oft den Fehler, dass er Scrum inklusive der heute bereitstehenden Werkzeuge und Techniken mit dem früher klassischen Prozess exklusive dieser Werkzeuge und Techniken vergleicht (da es diese eben damals noch nicht gab). Klarerweise scheint Scrum dann den „alten“ Vorgehensmodellen deutlich überlegen zu sein.

Frank Düsterbeck: Die heute modernen Praktiken und Methoden, die es teilweise schon länger als Scrum gibt (z. B. Automatisierung, XP, CCD, Story Mapping, Design Thinking, Microservices), können selbstverständlich auch in klassischen Umfeldern hilfreich sein. Durch die iterative Vorgehensweise, das Rollenmodell, die Transparenz, Inspektion und Adaption hat Scrum jedoch eindeutige Vorteile gegenüber klassischen sequenziellen Modellen.

Man darf auch nicht außer Acht lassen, dass einige klassische Vorgehensweisen Iterationen bzw. Rückkopplungen der verschiedenen Phasen eingeführt haben, da eine rein sequenzielle Abarbeitung einer komplexen Problemstellung eben falsch ist. Diese Rückkopplungen habe ich persönlich aber in noch keinem einzigen Wasserfallprojekt als bewussten Prozessschritt gesehen – schade!